home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 4 / QRZ Ham Radio Callsign Database - Volume 4.iso / digests / digital / 940172.txt < prev    next >
Internet Message Format  |  1994-11-13  |  23KB
  1. Date: Thu,  2 Jun 94 04:30:19 PDT
  2. From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu>
  3. Errors-To: Ham-Digital-Errors@UCSD.Edu
  4. Reply-To: Ham-Digital@UCSD.Edu
  5. Precedence: Bulk
  6. Subject: Ham-Digital Digest V94 #172
  7. To: Ham-Digital
  8.  
  9.  
  10. Ham-Digital Digest          Thu,  2 Jun 94       Volume 94 : Issue  172
  11.  
  12. Today's Topics:
  13.                     Alpha-Numeric Paging Software
  14.              An open note to Gary Coffman, KE4ZV (3 msgs)
  15.               Cardinal DSP16 boards $79 +$5s/h (2 msgs)
  16.                        Help with JNOS for Linux
  17.                             JNOS for Unix.
  18.                           LOOKING FOR: PK-88
  19.                          need repeater advice
  20.                               PCMCIA TNC
  21.                 RTTY DIGITAL JOURNAL subscription info
  22.           Telix modem software doesn't choke on 7plus files
  23.  
  24. Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu>
  25. Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu>
  26. Problems you can't solve otherwise to brian@ucsd.edu.
  27.  
  28. Archives of past issues of the Ham-Digital Digest are available 
  29. (by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital".
  30.  
  31. We trust that readers are intelligent enough to realize that all text
  32. herein consists of personal comments and does not represent the official
  33. policies or positions of any party.  Your mileage may vary.  So there.
  34. ----------------------------------------------------------------------
  35.  
  36. Date: 1 Jun 1994 22:50:57 GMT
  37. From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!wupost!udel!news2.sprintlink.net!news.sprintlink.net!bga.com!patm@network.ucsd.edu
  38. Subject: Alpha-Numeric Paging Software
  39. To: ham-digital@ucsd.edu
  40.  
  41. TSTADER (tstader@aol.com) wrote:
  42. : In article <2rt9s2$mpr@giga.bga.com>, patm@bga.com (Patrick Mcguire)
  43. : writes:
  44.  
  45. *** Thanks for the credit but  I this is *not* the response that I posted.***
  46.  
  47. vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
  48. : Somebody once gave me the info to Motorola's document request
  49. : line.... but not sure where I saw it.... but if you call
  50. : 1-800-542-7882 and ask them for a copy of the Motorola "Third Party
  51. : Referal Guide to Alpah and Data Paging"... you'll get a nice booklet
  52. : listing all of the "known" software suppliers out there whose
  53. : products do what you want. There is a section for DOS, Macintosh and
  54. : Unix. They have a section for Shareware/Freeware, but the 04 March
  55. : 1994 edition shows none.
  56.  
  57. : I don't know how Motorola will continue to support this document....
  58. : but it is nice. They also sent me a whole bunch of info on their
  59. : NewsStream and NewsCard products.... it got the wheels turning on we
  60. : might be able to adapt this product... pretty neat.
  61.  
  62. : 73 for now.... c u on the shortwaves
  63. : Terry Stader - KA8SCP
  64. : America Online Ham Radio Club Host
  65. : Macintosh Amateur Radio Software List Maintainer
  66. : Internet: tstader@aol.com (e-mail)  or
  67. :           p00489@psilink.com (binaries/files >28K)
  68. : KA8SCP@WA1PHY.#EMA.MA.USA.NOAM
  69. : ka8scp@ka8scp.ampr.org [44.56.4.82] Mac
  70. :                        [44.56.4.120] DOS Clone
  71. : (they're BOTH pc's!)
  72. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  73.  
  74. What I did originally post was a short note concering the use of any 
  75. generic comm program to access an alphanumeric pager.
  76.  
  77. A short recap of this follows:
  78.  
  79. Obtain the paging terminal access telephone no from the pager co.  This 
  80. is the number you must have regardless of the access software you use.
  81.  
  82. Set your comm program to 1200 bps N81 at first.  If this does not work 
  83. use 300 bps.  These terminals are not speed demons.
  84.  
  85. When the terminal answers it will ask for password.  In my experience 
  86. this is just the name of the paging co. or some variant.  (e.g. McCaw 
  87. Communications is "MCCAW")
  88.  
  89. Next you will be queried for the number of the pager.  Enter the 
  90. telephone number of pager -just 7 digits, no area code.
  91.  
  92. Then just enter the text of your message, usually 80 chars max.
  93.  
  94. That's all there is to it...  If you are so inclined a 'script' could be 
  95. written that would enter all the preamble stuff automatically.
  96.  
  97. Patrick McGuire  WA8PLR
  98. patm@bga.com
  99.  
  100. ------------------------------
  101.  
  102. Date: 1 Jun 1994 15:25:57 GMT
  103. From: ihnp4.ucsd.edu!swrinde!cs.utexas.edu!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!icaen!drenze@network.ucsd.edu
  104. Subject: An open note to Gary Coffman, KE4ZV
  105. To: ham-digital@ucsd.edu
  106.  
  107. Gary, you should be getting a copy of this on Packet as well, but I
  108. thought I'd toss it out on Usenet as well for others to comment upon.
  109.  
  110. I recently came across a note by you in our local Packet BBS archives
  111. dated 12-MAR-92.  You probably don't remember having written it, but
  112. it was a response to a UK user's request for information on packet
  113. applications.
  114.     Your response was that there was so much potential for
  115. packet, but that right now, aside from local packet BBS's and 
  116. packet mail, there are none, diddly, zippo.  You said that, you
  117. expected it "to fall into a 1200 baud and C64 forever mindset that
  118. never reaches the heights it is capible of scaling."
  119.     Well, two years later, I see you as being 100% right.  I've
  120. not been in packet that long, but what I've seen makes me believe that
  121. the case may be worse than you depicted it then.  I'll use the Iowa
  122. packet network as an example.  It's a fairly extensive network, you
  123. can get into it from pretty much anyplace in the state on 2-meters.
  124. But I have the network map here in front of me...and that's about
  125. all it is, 2 meters.  There are only a handful of 9600 baud connections
  126. throughout the state, and those are mostly to get *into* nodes, not
  127. links between the nodes, and the few which are backbone links don't
  128. even connect the major nodes.  I hear people talking on the linked
  129. repeater system about mail moving "fast" today--only taking 16 hours
  130. or so to make a 3-link trip.  Needless to say, I have a hard time
  131. swallowing that.
  132.     I realize that much of this is simply the way the local net
  133. is set up, but the way it is set up reflects the mindset of which
  134. you wrote.  Also, from my conversations with other packeteers, this
  135. sort of setup is not uncommon.
  136.     But what can be done about it?  It seems to me that newer,
  137. more efficient protocols need to be developed *and actively promoted*
  138. rather than making 10 or 15-year-old technology the standard.
  139.     A new implementation of TCP/IP might even help the situation.
  140. While the TCP/IP protocol suite is far from perfect, it seems to be
  141. much more efficient than the network we have now.  But the current
  142. implementations, while pioneering in their time, are currently out-
  143. dated.  IMO the best way to update our current technology would be
  144. to develop a device driver for the standard TNC in KISS mode.  This
  145. device driver would allow standard TCP/IP implementations and apps
  146. to interface to amateur packet radio transparently.  It seems to me
  147. that there is no reason that standard TCP/IP applications which run
  148. on the Internet should not be able to run on a Packet radio internet,
  149. including standard implementations of ftp, telnet, rlogin, usenet news,
  150. internet bbs's, etc.  I have been dabbling with such a device driver,
  151. but I do not pretend to either be a professional programmer (I'm a
  152. writer by trade) or to understand the AX.25 protocol or to understand
  153. KISS.
  154.     Furthermore, this would be an excellent avenue to bring new
  155. blood into Amateur Radio.  I've mostly grown up with computers, but
  156. as great as my understanding of them is, I don't have the intuitive
  157. understanding that those even ten years younger than me do.  I've only
  158. been using computers since I was ten or so...these kids currently in
  159. high school have been living with their wonders since the day they were
  160. born.  These are the ones we should be talking to, that we should be
  161. bringing into Amateur Radio to develop the networks of tomorrow.  With
  162. their help we could put Amateur Radio back on the cutting edge of
  163. technology rather than the trailing edge we seem to be holding on to
  164. right now.
  165.  
  166. Comments?  I'm interested in hearing what people have to say.  You
  167. can please direct any flames to /dev/null--I don't want to hear them.
  168.  
  169. -- 
  170.          Doug Renze, N0YVW * drenze@isca.uiowa.edu * N0YVW @ W0IUQ.ia.usa.na
  171.  
  172. ------------------------------
  173.  
  174. Date: Thu, 2 Jun 1994 00:24:25 GMT
  175. From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!europa.eng.gtefsd.com!darwin.sura.net!fconvx.ncifcrf.gov!mack@network.ucsd.edu
  176. Subject: An open note to Gary Coffman, KE4ZV
  177. To: ham-digital@ucsd.edu
  178.  
  179. In article <2si9a5$40g@news.icaen.uiowa.edu> drenze@icaen.uiowa.edu (Douglas J Renze) writes:
  180.  
  181. >    But what can be done about it?  It seems to me that newer,
  182. >more efficient protocols need to be developed *and actively promoted*
  183. >rather than making 10 or 15-year-old technology the standard.
  184. >    A new implementation of TCP/IP might even help the situation.
  185. >While the TCP/IP protocol suite is far from perfect, it seems to be
  186. >much more efficient than the network we have now.  But the current
  187. >implementations, while pioneering in their time, are currently out-
  188. >dated.  IMO the best way to update our current technology would be
  189. >to develop a device driver for the standard TNC in KISS mode.  This
  190. >device driver would allow standard TCP/IP implementations and apps
  191. >to interface to amateur packet radio transparently.  It seems to me
  192. >that there is no reason that standard TCP/IP applications which run
  193. >on the Internet should not be able to run on a Packet radio internet,
  194. >including standard implementations of ftp, telnet, rlogin, usenet news,
  195. >internet bbs's, etc. 
  196.  
  197. TCPIP is already available with the KA9Q NOS code (there's lots of books
  198. eg NOS INTRO, thru ARRL, to helpyou on your way). There is a problem that 
  199. there's no one to talk to. The real problem is that increased data rate
  200. requires a wider IF and AF section in the T/X. The current voice grade
  201. audio that comes through ham FM rigs is only good to about 2400 baud (others
  202. probably have better estimates). If you want 56kb, then you need a whole 
  203. new TX, basically an RF modem. To talk at ethernet rates (10MHz) you are
  204. going to have to put all your rigs on 10Ghz. It's a lot of money to invest
  205. in a system which is hobbled by every message having to be read by a human
  206. at the point of entry.
  207.  
  208.     Joe Mack NA3T
  209.     mack@ncifcrf.gov
  210.  
  211. ------------------------------
  212.  
  213. Date: 2 Jun 1994 04:36:06 GMT
  214. From: ihnp4.ucsd.edu!agate!howland.reston.ans.net!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!icaen!drenze@network.ucsd.edu
  215. Subject: An open note to Gary Coffman, KE4ZV
  216. To: ham-digital@ucsd.edu
  217.  
  218. mack@ncifcrf.gov (Joe Mack) writes:
  219.  
  220. >In article <2si9a5$40g@news.icaen.uiowa.edu> drenze@icaen.uiowa.edu (Douglas J Renze) writes:
  221.  
  222. >>    But what can be done about it?  It seems to me that newer,
  223. >>more efficient protocols need to be developed *and actively promoted*
  224. >>rather than making 10 or 15-year-old technology the standard.
  225. >>    A new implementation of TCP/IP might even help the situation.
  226. >>While the TCP/IP protocol suite is far from perfect, it seems to be
  227. >>much more efficient than the network we have now.  But the current
  228. >>implementations, while pioneering in their time, are currently out-
  229. >>dated.  IMO the best way to update our current technology would be
  230. >>to develop a device driver for the standard TNC in KISS mode.  This
  231. >>device driver would allow standard TCP/IP implementations and apps
  232. >>to interface to amateur packet radio transparently.  It seems to me
  233. >>that there is no reason that standard TCP/IP applications which run
  234. >>on the Internet should not be able to run on a Packet radio internet,
  235. >>including standard implementations of ftp, telnet, rlogin, usenet news,
  236. >>internet bbs's, etc. 
  237.  
  238. >TCPIP is already available with the KA9Q NOS code (there's lots of books
  239. >eg NOS INTRO, thru ARRL, to helpyou on your way). There is a problem that 
  240. >there's no one to talk to. The real problem is that increased data rate
  241. >requires a wider IF and AF section in the T/X. The current voice grade
  242. >audio that comes through ham FM rigs is only good to about 2400 baud (others
  243. >probably have better estimates). If you want 56kb, then you need a whole 
  244. >new TX, basically an RF modem. To talk at ethernet rates (10MHz) you are
  245. >going to have to put all your rigs on 10Ghz. It's a lot of money to invest
  246. >in a system which is hobbled by every message having to be read by a human
  247. >at the point of entry.
  248.  
  249. I'm aware that TCP/IP is already available.  But this is a suite of
  250. programs which operate only through packet, if I'm not mistaken.  Ideally,
  251. any program which can run through standard TCP/IP should be able to run
  252. through a packet-radio version of TCP/IP.  As far as I know, this is not
  253. currently the case.  If I'm using a Macintosh, for example, and want to
  254. use TCP/IP I *ought* to be able to use NCSA telnet, ditto for Windoze,
  255. standard telnet should work for me on a Linux box, and the DOS version
  256. of it should work on a DOS box.  Understand what I'm saying?
  257.     And who said anything about Ethernet rates?  Seems to me that
  258. a lot of people run SLIP at 9600 baud and don't have many problems.  Heck,
  259. I've even heard the rumour that all of Iceland is linked to the rest of
  260. the Internet through a single 9600 baud SLIP link.  Similar performance
  261. should be possible via packet (I mean, if LANs can do it, why can't we?).
  262. A packet network should be treatable as a WAN.
  263.  
  264. I've also been thinking some more about some applications for Packet.
  265. Why don't we use a Client-Server architecture for our BBS's?  It's much
  266. more efficient both in the use of the frequency and in the use of the
  267. host computer.
  268.     Why not write distributed BBS's, where multiple computers at
  269. different sites share the loads?  This is an offshoot of the client-
  270. server architecture.
  271.     There are so many possibilities!
  272.  
  273. 73 - doug
  274.  
  275. -- 
  276.          Doug Renze, N0YVW * drenze@isca.uiowa.edu * N0YVW @ W0IUQ.ia.usa.na
  277.                          DRenze@aol.com ** drenze@chop.isca.uiowa.edu
  278.  
  279. ------------------------------
  280.  
  281. Date: Wed, 1 Jun 1994 21:52:24 GMT
  282. From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!noc.near.net!analog.com!analog.com!kangas@network.ucsd.edu
  283. Subject: Cardinal DSP16 boards $79 +$5s/h
  284. To: ham-digital@ucsd.edu
  285.  
  286. In article <CqJDL1.JEv@sunsrvr6.cci.com> jdc@cci.com (James D. Cronin) writes:
  287. >In article <1994May27.185206.22868@midway.uchicago.edu>,
  288. >Kenneth C Hopper <khopper@midway.uchicago.edu> wrote:
  289. >>  For those digitally enabled  hams  who  are  in-
  290. >>  terested  in   exploring  the KC7WW PC soundcard
  291. >>  application - you can get a Cardinal  DSP16  for
  292. >>  $79  at  the  PC  Connection 1-800-243-8088 plus
  293. >>  about  $5  s/h.  Good deal  for  a  programmable
  294. >>  ASP based DSP PC board.
  295. >>
  296. >It sounds interesting.  What's needed in the line of software for
  297. >programming it?  Is there a developer's kit or something of that
  298. >nature?
  299. >Also, what ham-oriented software has been written for this card?
  300.  
  301. Note that the Cardinal board isn't ASP based, but instead has a real
  302. DSP onboard, an Analog Devices 2115. I have no idea if any ham software
  303. has been written for it, but Analog is supposed to release an SDK for
  304. the Cardinal and the other PSA-based soundcards (ie Orchid Soundwave,
  305. MediaMagic, Adaptec, etc.) Real Soon Now... which means I thought it
  306. was supposed to be out a couple of weeks ago, but seems to have been
  307. postponed a little bit. If you're interested, the official announcement
  308. should be on comp.dsp sometime soon.
  309.  
  310. Hmm... that is a pretty good price on the card, though. Might have to
  311. pick on of 'em up myself.
  312.  
  313. (ps - I'm not a ham... yet. just another interested bystander.)
  314.  
  315.         -Matt
  316.  
  317. -- 
  318.  . . . . . , , , , , , , , , , , . . . . . . . . . . . . . . . . . . . . . .
  319. Matt Kangas `,`,`,`,`,`,`,`,`,`,`,"(Thus we join television in leading people 
  320. matt.kangas@analog.com `,`,`,`,`,`,`,`,`,`,`,` to kill thoughtlessly.)"  -RMS
  321. DSP Tools Group, Analog Devices Inc `,`,`,`,`,`,`,`,`,`,`[Emacs, you know...]
  322.  
  323. ------------------------------
  324.  
  325. Date: 1 Jun 1994 22:56:01 -0400
  326. From: newstf01.cr1.aol.com!search01.news.aol.com!not-for-mail@uunet.uu.net
  327. Subject: Cardinal DSP16 boards $79 +$5s/h
  328. To: ham-digital@ucsd.edu
  329.  
  330. In article <1994Jun1.215224.4951@analog.com>, matt.kangas@analog.com
  331. writes:
  332.  
  333. In article <CqJDL1.JEv@sunsrvr6.cci.com> jdc@cci.com (James D.
  334. Cronin) writes:
  335. >In article <1994May27.185206.22868@midway.uchicago.edu>,
  336. >Kenneth C Hopper <khopper@midway.uchicago.edu> wrote:
  337. >>  For those digitally enabled  hams  who  are  in-
  338. >>  terested  in   exploring  the KC7WW PC soundcard
  339. >>  application - you can get a Cardinal  DSP16  for
  340. >>  $79  at  the  PC  Connection 1-800-243-8088 plus
  341. >>  about  $5  s/h.  Good deal  for  a  programmable
  342. >>  ASP based DSP PC board.
  343. >>
  344. >It sounds interesting.  What's needed in the line of software for
  345. >programming it?  Is there a developer's kit or something of that
  346. >nature?
  347. >Also, what ham-oriented software has been written for this card?
  348.  
  349. A friend and I bought 3 of these boards several months ago they were
  350. such a "bargain" (about $120).  
  351.  
  352. We had so many problems with software and drivers and installation,
  353. we sent them back!  Cardinal Tech Support was useless.  
  354.  
  355. Sometimes you get what you pay for!
  356.  
  357. Anyone need the Wavetable Chip for this Board??
  358.  
  359. ------------------------------
  360.  
  361. Date: 1 Jun 1994 21:37:03 -0400
  362. From: newstf01.cr1.aol.com!search01.news.aol.com!not-for-mail@uunet.uu.net
  363. Subject: Help with JNOS for Linux
  364. To: ham-digital@ucsd.edu
  365.  
  366. Benn trying to get JNOS (j109lxa3) working. When I compile,
  367. everything goes fine until it gets near the end, then I get
  368. "curses.c XXX (linux.a(curses.o)) Undefined symbol _getattrs
  369. referenced from text segment"
  370. This is repeated 5 times, with 5 line numbers (XXX), 434,489,496,524,
  371. 533) . I loaded ncurses 1.8, and even changed my kernel from 99.14 to
  372. 1.10, but the error is the same.
  373. Obviously, I am no expert on C programming. Has anyone had the same
  374. experience, and can tell me what to do. Dumb I may be, bur also
  375. stubborn, and have benn struggling with this for 3 days.
  376.  
  377. Thanks in advance..
  378.  
  379. John N4JS (jsielke@wx2l.uscc.com)
  380.  
  381. ------------------------------
  382.  
  383. Date: 1 Jun 1994 14:24:02 -0400
  384. From: newstf01.cr1.aol.com!search01.news.aol.com!not-for-mail@uunet.uu.net
  385. Subject: JNOS for Unix.
  386. To: ham-digital@ucsd.edu
  387.  
  388. Try UCSD.EDU in hmradio/packet/jnos. You want j109lxa3.tar.z
  389.  
  390. ------------------------------
  391.  
  392. Date: Wed, 1 Jun 1994 14:55:42 GMT
  393. From: ihnp4.ucsd.edu!swrinde!cs.utexas.edu!convex!news.duke.edu!concert!hearst.acc.Virginia.EDU!saips.cv.nrao.edu!sadira.gb.nrao.edu!dgordon@network.ucsd.edu
  394. Subject: LOOKING FOR: PK-88
  395. To: ham-digital@ucsd.edu
  396.  
  397. I am looking for a used PK-88 for use with my C64. Got the
  398. software, just need the modem and cables. Thanks
  399.  
  400. David - KB4LCI
  401. dgordon@nrao.edu
  402.  
  403. ------------------------------
  404.  
  405. Date: Wed, 1 Jun 1994 20:01:45 GMT
  406. From: spsgate!mogate!newsgate!dtsdev0!kinzer@uunet.uu.net
  407. Subject: need repeater advice
  408. To: ham-digital@ucsd.edu
  409.  
  410.   There seems to be very little packet activity in this area (Phoenix)
  411. on 440 MHZ.  Around our club, we were kicking around the idea of 
  412. putting up a small BBS or something, just to get our hands into
  413. the packet arena.  The idea kept evolving until we found ourselves
  414. talking about putting up a full blown repeater for digital use (we
  415. already have voice repeaters.)  We think we can scrounge up the
  416. necessary radio equipment, and are continuing thinking along these
  417. lines.
  418.  
  419.   So, with setting up a repeater as the goal, what do we need to do 
  420. to make a deluxe installation?  I see operation at 9600 baud as
  421. a possibility, even though I (nor nobody I know) does 9600 at
  422. the present time.  We would probably be setting a precedent for 
  423. the area on 440, and thus should do the job well.
  424.  
  425.   There appears to be a bit-regenerator kit from TAPR, but I am not
  426. networked well with that organization yet (new member.)  Is this
  427. the way to go, or is there some other option to consider?  Anyway,
  428. fire away, and we'll see what we can come up with.
  429.  
  430. -dave
  431.  
  432. ------------------------------
  433.  
  434. Date: 1 Jun 1994 22:42:32 GMT
  435. From: pa.dec.com!usenet@decwrl.dec.com
  436. Subject: PCMCIA TNC
  437. To: ham-digital@ucsd.edu
  438.  
  439. Anyone know if someone is looking at doing a PCMCIA TNC? I think that this would
  440. be a neat item. (I know I could put it to good use).
  441.  
  442. Any pointers would be appreciated.
  443.  
  444. 73 de Jeff -- KD1IT/7
  445.  
  446. --------------------------------------------------------------------------------------------------------------------------------------
  447. Jeff McLeman                                                        Internet: mcleman@zso.dec.com
  448. Redmond, Wa.                                                       Amprnet: jeffm@kd1it.ampr.org
  449. KD1IT / 7                                                                AX25 slownet: kd1it@n7fsp.wa.usa.na
  450.  
  451. ------------------------------
  452.  
  453. Date: 1 Jun 1994 14:56:18 GMT
  454. From: nwnexus!krel.iea.com!comtch!mikec@uunet.uu.net
  455. Subject: RTTY DIGITAL JOURNAL subscription info
  456. To: ham-digital@ucsd.edu
  457.  
  458. Kenneth C Hopper (khopper@kimbark.uchicago.edu) wrote:
  459. : Great source of info about all digital ham modes. Give it
  460. : a try for $19 (first class US)/yr.
  461.  
  462. :     The rtty DIGITAL Jouranl
  463. : c/o The American Digital Radio Society
  464. :     P.O. Box 2465
  465. :     New York, NY 10185-2465
  466.  
  467. : or  Jim, N2HOS
  468. :     P.O. Box 3328
  469. :     Indian Rocks Beach, FL 34635
  470.  
  471. : I am not affiliated with the RDJ in any way - but I feel
  472. : it is the digital ham's best publication and I want you
  473. : to know about it :-).
  474.  
  475. I _am_ affiliated with the RDJ, and I have to agree with you -
  476. the Journal is an excellent source of digital information!
  477. --
  478. - - - - - - - - - - - -  mikec@comtch.iea.com  - - - - - - - - - - - - - - -
  479.  
  480. Michael B. Candy                            Amateur Radio Call: KI7FX
  481. P.O. Box 1953                               KI7FX@KA7FVV.#EWA.WA.USA.NA
  482. Airway Hts, WA. 99001-1953                  American Digital Radio Society  
  483.  
  484.                                               
  485.  
  486. ------------------------------
  487.  
  488. Date: Wed, 1 Jun 1994 11:36:18 GMT
  489. From: psinntp!gdstech!gdstech!bat@uunet.uu.net
  490. Subject: Telix modem software doesn't choke on 7plus files
  491. To: ham-digital@ucsd.edu
  492.  
  493.  Any time you are sending binary files over a modem you run the risk
  494. of wierd things happening, as the XON/XOF characters are encountered
  495. in
  496. the stream. Using hardware flow control is almost always a better bet.
  497. Set your comm software (and sometimes a modem setting is needed) to
  498. use
  499. RTS/CTs and you will have lots fewer transmission problems. BTW, I use
  500. the new MSKermit, and it works great, and is free. -pat
  501. -- 
  502. *-----------------------------------------------------------*
  503. *     Pat Masterson   D12-25  | KE2LJ@KC2FD                 *
  504. *     Grumman Data Systems    | 516-346-6316.               *
  505. *     Bethpage, NY 11746      | bat@gdstech.grumman.com     *
  506.  
  507. ------------------------------
  508.  
  509. End of Ham-Digital Digest V94 #172
  510. ******************************
  511.